Sempre é satisfatório compartilhar novas formas poderosas de resolver problemas, especialmente quando a solução esteve "escondida à vista de todos" por um tempo. Desta vez, estou mostrando como a combinação de ArcGIS Enterprise branch versioning e cloud native data sharing oferece não apenas acesso rápido aos dados, para pessoas sem acesso ao portal, mas também a capacidade de pedir aos dados acessados que viajem no tempo para quando eram mais jovens. Como esses lotes, veja um lote anteriormente indiviso e agora suas três subdivisões.<\/P>
Parcel subdivision<\/span><\/span>Parcel subdivision<\/SPAN><\/SPAN><\/SPAN><\/P>Imagine um conjunto de dados com milhões de feições e sob manutenção diária intensa, como o branch versioning foi projetado para lidar, seus clientes podem acessar toda ou qualquer parte da versão padrão para qualquer momento no tempo. Para sempre. Sem carga extra no seu portal Enterprise.<\/P>Então, como cheguei lá? Simplesmente percebi que o modelo de transação somente inserção do branch versioning é adequado para criar incrementalmente arquivos GeoParquet em armazenamento na nuvem que preservam conjuntamente o estado dos dados ao longo do tempo e podem ser consultados espacialmente e temporalmente para gerar dados locais sob demanda para sua área e período de interesse.<\/P>No entanto, é uma consulta muito sofisticada! A boa notícia é que você não precisa descobrir isso sozinho, o download do blog inclui um notebook com exemplos para meu assunto de lote, basta inserir os seus.<\/P>Não precisei inventar a abordagem da consulta, a Esri publica materiais de workshop sobre o tema. Por exemplo, se você for por volta do minuto 18 nesta apresentação, verá como essa consulta se parece.<\/P>Spoiler<\/a>adicionar a classe archive ao mapa eles ficam disponíveis:<\/P>
Archive class added to the map<\/span><\/span>Archive class added to the map<\/SPAN><\/SPAN><\/SPAN><\/P>Algumas coisas a notar no mapa dos campos: ObjectID é rebaixado para um inteiro longo comum (os valores não são mais únicos) e vários campos chamados GDB_* são adicionados. Eles permitem visualizar os dados em um momento no tempo, que é como o branch versioning funciona - o estado mais recente para uma feição prevalece, que pode ser um estado excluído, mas o histórico dos dados não é perdido (a menos que você o descarte), o que torna possível a viagem no tempo.<\/P>A classe archive também é útil para descobrir quais momentos de edição estão nos seus dados.<\/P>Com a classe archive fornecendo visibilidade para todos os campos, o fluxo de trabalho de compartilhamento e manutenção foi possível. Funciona assim:<\/P>Criar um arquivo parquet inicial com todas as linhas da classe archive onde GDB_BRANCH_ID = 0<\/LI>Em qualquer cronograma que faça sentido, criar arquivos delta parquet para novos estados das linhas da branch padrãoEstes têm uma GDB_FROM_DATE posterior ao máximo em todos os arquivos parquet existentes<\/LI>E também têm GDB_BRANCH_ID = 0<\/LI><\/UL><\/LI>Manter todos os arquivos parquet na sua loja de objetos compatível com S3 favorita em um caminho glob<\/LI>Fornecer aos seus clientes de dados um notebook ou ferramenta script que eles possam usar para extrair dadosO notebook fornecido requer DuckDB versão 1.0.0 no ambiente Python<\/LI><\/UL><\/LI><\/UL>Agora, estou anunciando isso como distribuição nativa da nuvem, mas no momento estou configurando minha conta AWS então o notebook anexado está usando um caminho local do sistema de arquivos, atualizarei isso quando tiver um caminho público S3 disponível. Enquanto isso você pode baixar dados amostra para teste aqui, aqui, aqui e aqui. São a cópia inicial em massa da versão e alguns arquivos delta incrementais, com algumas edições diárias cada. Altere a variável pqPath do notebook conforme seu ambiente até eu colocar o caminho S3 disponível.<\/P>Spoiler<\/A>Os dados que estou usando não estão realmente sendo mantidos em uma geodatabase versionada por branch, eu criei dados amostra, por favor veja as permissões dos dados nos detalhes do item nos links acima.<\/DIV>
Os dados que estou usando não estão realmente sendo mantidos em uma geodatabase versionada por branch, eu criei dados amostra, por favor veja as permissões dos dados nos detalhes do item nos links acima.<\/DIV><\/DIV>
Você verá no notebook que forneço um modelo para consultas por extensão e viagem no tempo. Eu consigo extrair todos os 2.7 milhões de lotes nos meus dados em pouco mais de 3 minutos, do disco local. O acesso via S3 eu espero que seja um pouco mais lento, veremos quando eu configurar isso. Experimente o notebook você mesmo.<\/P>
Você pode ter algumas perguntas sobre o notebook, vou tentar antecipar algumas:<\/P>
- DuckDB 1.0.0 é usado pois está no canal Esri Conda e versões posteriores tratam geometria diferentemente<\/LI>
- A coluna bbox nos arquivos parquet é do tipo JSON mas consultada como varchar pois DuckDB parecia não reconhecer os dados como JSON<\/LI>
- Tentei usar a pseudocoluna rowid embutida no DuckDB mas obtive erros, então substituí ela<\/LI>
- Tentei escrever a classe de feição saída passando por um dataframe habilitado espacialmente mas obtive erros<\/LI>
- No download do blog o projeto atbx tem uma ferramenta script que usei para encontrar larguras desejadas dos campos texto saída<\/LI><\/UL>
Agora vou ser um pouco egoísta. Para fazer meus dados amostra e arquivos parquet construí algumas ferramentas ETL (Pro 3.4), que eu poderia ter scriptado. Essas ferramentas não estão no download do blog. Se você estiver interessado nelas por favor me envie uma mensagem e posso compartilhar. Isso ajudará a equipe aqui se soubermos quantas pessoas estão interessadas neste paradigma de compartilhamento de dados, então por favor nos ajude a ajudar você.<\/P>
